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DETAILED ACTION 

1 . This action is responsive to the Applicant's response filed 1 1/22/2005. 

As indicated in Applicant's response, resubmitted claims 1-56 are pending in the office 

action. 

Specification 
Abstract 

2. The abstract of the disclosure is objected to because the permitted maximum number of 
words allowed has been exceeded. Correction is required. See MPEP § 608.01(b). 

Claim Rejections - 35 USC § 101 

3. 35 U.S.C 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or 
any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 

The Federal Circuit has recently applied the practical application test in deterriiining whether the claimed 
subject matter is statutory under 35 U.S.C. § 101. The practical application test requires that a " useful, 
concrete, and tangible result" be accomplished. An "abstract idea" when practically applied is eligible for a 
patent As a consequence, an invention, which is eligible for patenting under 35 U.S.C. § 101, is in the 
"useful arts" when it is a machine, manufacture, process or composition of matter, which produces a 
concrete, tangible, and useful result. The test for practical application is thus to determine whether the 
claimed invention produces a "useful, concrete and tangible result". 

4. Claims 1-2, 6-10, 29-30, and 34-38 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. 

Specifically, claim 1 recites a method claim having one step of processing a definition of 
a function to create description information. The intention of this single step of processing is to 
create information about the function; and although there is recital of additional descriptive 
specification about the targeted abstract entity recited as description information - that this 
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information is 'sufficient to enable translation' of a call- one skill in the art would not be 
apprised on existence of (i) a functional and concrete step acting upon the elements recited; (ii) a 
targeted, useful and tangible result being the consequence of an action using/operated upon the 
description information thus claimed. In other words, reciting that some information is 
sufficient for enabling something does not convey one explicit step (of the method claim) that is 
an action actually taken to accomplish any tangible result, when such information has been 
construed as an abstract entity. The method claim revolves about this single step of processing 
for generating a concept (information about a function) that appears to be left without any clear 
purposeful action performed upon or using it; hence this is not fulfilling a concrete useful result 
pursuant, say, to the State Street Bank case. And as such, the claim amounts to an abstract idea, 
i.e. does not amount to a practical application because it fails to yield a concrete, useful and 
tangible result as required by the above-mentioned Practical Application Test. The claim is 
rejected for leading to a non-statutory subject matter. 

Dependent claims 2 and 6-10 for not remedying to the abstract idea deficiency of the base 
claim are also rejected. 

Claim 29 recites computer-readable instructions to process a definition in a first language 
to create description information sufficient to enable translation of a call similar to what has been 
recited above. The so-called description information being sufficient to enable a translation does 
not convey that an action by the program instructions is taken so that it would perform the 
recited the recited translation of a function call; thus this description information is not perceived 
as being one explicit action actually taken to accomplish any tangible, useful result pursuant to 
the State Street Bank case, as mentioned above. As a whole, the claim amounts to a product 
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claim in which an apparatus ( computer-media code) is processing what is perceived as an 
abstract idea ( definition of a function) without carrying out the input to this process in terms of 
an action leading toward a tangible, concrete and useful result (e.g. description information 
merely described in terms of broad potential capabilities). Claim 29 amounts to a non-practical 
application, i.e. an abstract idea, because it fails to yield a concrete, useful and tangible result as 
required by the above-mentioned Practical Application Test. The claim is rejected for leading to 
a non-statutory subject matter. 

Dependent claims 30 and 34-38 for not remedying to the abstract idea deficiency of the 
base claim are also rejected. 

Claim Rejections - 35 USC § 112 

5. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

6. Claim 1, 1 1, 21, 29, 39, and 49 rejected under 35 U.S.C. 1 12, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. 

The term sufficient in "sufficient to enable translation" in claims 1, 1 1, 21, 29, 39, and 49 
is a relative term which renders the claim indefinite. The term "sufficient" is not defined by the 
claim, the specification does not provide a standard for ascertaining the requisite degree, and one 
of ordinary skill in the art would not be reasonably apprised of the scope of the invention. The 
claim has to set forth the metes and bounds of a limitation; and by saying that a entity is 
'sufficient' there is no basis for one skill in the art to ascertain on the degree or terms this 
qualifier is measured by or quantified into. There is no teaching in the specifications to 
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explicitly provide a reasonable semantic expansion of such term recited as 'sufficient'; hence the 
term remain indefinite; and broad reasonable interpretation for this limitation will be applied. 

All dependent claims to the above base claims are also rejected; making claims 1-56 all 
rejected. 

Claim Rejections - 35 USC § 102 

7. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of application for patent in the United States. 

8. Claims 1-7, 1 1-13, 17, 20, 29-35, 39, 40-41, 45, and 48 are rejected under 35 
U.S.C. 102(b) as being anticipated by Shannon et al., "Mapping the Interface Description 
Language Type Model in C", November 1989, IEEE Transactions on Software Engineering, Vol. 
15, No. 1 1 ( hereinafter Shannon). 

As per claim 1, Shannon discloses a method comprising 

processing a definition of a function associated with the first language about a function in 
a first language (e.g. IDL specification ... specifically, C macros ... and functions - pg. 1334, left 
column, 4 para; . . . existing languages ... LISP, Diana structures ... mapped ...to C, Ada 
Breadboard Compiler - Introduction pg. 1333-1334; . . .data structures found in procedural 
programming languages - 2 nd para, right column, pg. 1334; node declaration ... function => 
name; String; parameters: Seq of ... formal parameters, pg. 1334, right column; class, function - 
Fig. 1 pg. 1335; Process declaration - Fig. 2) to create the description information or IDL {IDL 
specifications - Fig. 3, pg. 1336; IDL specification ... specifically, C macros ... and functions - 



Application/Control Number: 09/9 11,819 Page 6 

Art Unit: 2193 

pg. 1334, left column, 4 th para - Note: The conversion based on a special package extending 
existing language structures to target C or Ada reads on creating a description interface on 
structures, e.g. a class definition, in first language, - into Ada function or C data structures; data 
structures found in procedural programming languages - 2 nd para, right column, pg. 1334 - 
Note: the use of existing programming constructs reads on function in first language when data 
structure is inherent to function of a language), 

the description being sufficient to enable translation of a call to the function into a call to 
a corresponding function in a second language (. . .should be permitted by the C compiler - 
Introduction pg. 1333-1334) without requiring processing of the definition of the function (e.g. 
. . . should be natural and not require knowledge of implementation details - pg. 1333, right 
column). 

As per claims 2 and 4, Shannon discloses a file of description items and derived 
description information (e.g. sections II, in - pg. 1334-1339). 
As per claim 3, Shannon discloses 

examining the definition of the function associated with the first language (e.g. . . .data 
structures found in procedural programming languages - 2 nd para, right column, pg. 1334; node 
declaration ...function => name; String; parameters: Seq of ... formal parameters, pg. 1334, 
right column - Note: the fact of creating appropriate parameters for a function disclose 
examining definition of a function in a source language); 

using derived information (IDL specifications - Fig. 3, pg. 1336; IDL specification ... 
specifically, C macros ... and functions - pg. 1334, left column, 4 th para) about the function to 
translate the call to the function into a call to a corresponding function in the second language 
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(e.g. section III pg. 1336; Fig. 3; function call ... procedure call - last 2 paras, right column pg. 
1343 - Note: C is the second language and node structures for function call at runtime compiler 
read on using IDL specifications to generate translation of function call in target language). 

As per claim 5, Shannon discloses creation of C language constructs, hence has 
implicitly disclose the Jib files associated with the assembling of object files prior to linking in 
C. Therefore, Shannon has implicitly disclosed library wherein entries associated with the 
assembling process in C compiler because at the time the invention was made it was a known 
concept that C compiler create lib files during a pre-linking compiler process. 

As per claims 6 and 7, Shannon discloses a declaration with a set of input and output 
port (ch. B - pg. 1335; Fig. 2, pg. 1336) and input/output mapping ( pg. 1338, Private types - 
right column); hence has disclosed analysis of the first language input/output formal parameters 
leading to creation of C formal parameters, i.e. list of input or output/return parameters otherwise 
the target function declaration would not result in a correct function declaration ( Note: the 
declaration of formal input and output, and scope of variables declared in a function in 4 th 
generation like C was a known concept at the time the invention was made; and according to C 
code translation by Shannon, this reads on input/outputs as in a formal declaration of a function 
as set forth in claims 1, 3). 

As per claim 11, Shannon discloses providing a file of description items, information 
about a function in a first language (e.g. Diana structures ... mapped ..JoC, Ada Breadboard 
Compiler - Introduction pg. 1333-1334; . . .data structures found in procedural programming 
languages - 2 nd para, right column, pg. 1334; node declaration ... function => name; String; 
parameters: Seq of ...formal parameters, pg. 1334, right column; class, function - Fig. 1 pg. 
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1335), the description being sufficient to enable translation of a call to the function into a call to 
a corresponding function in a second language (. . .should be permitted by the C compiler - 
Introduction pg. 1333-1334) without requiring processing of the definition of the function (e.g. 
. . . should be natural and not require knowledge of implementation details - pg. 1333, right 
column); and 

using information about a function associated with the first language to translate a first 
program file into a second program file (. . .data structures found in procedural programming 
languages - 2 nd para, right column, pg. 1334; node declaration ...function => name; String; 
parameters: Seq of ... formal parameters, pg. 1334, right column; class, function - Fig. 1 pg. 
1335 - Note: using existing programming language source to analyze structures in order to 
generate IDL constructs reads on using information about function in 1 st language to translate a 
first program into a second program file - see pg. 1344 Runtime efficiency: mapping, compiler). 

As per claims 12-13, referring to rationale of claims 6-7, Shannon has disclosed analysis 
of the first language input/output formal parameters leading to creation of C formal parameters, 
i.e. list of input or output/return parameters otherwise the target function declaration would not 
result in a correct function declaration ( Note: the declaration of formal input and output, and 
scope of variables declared in a function in 4 th generation like C was a known concept at the time 
the invention was made; and according to C code translation by Shannon, this reads on 
input/outputs as in a formal declaration of a function as set forth in claims 1, 3). 

As per claim 17, Shannon teaches using existing programming language source to 
analyze structures in order to generate IDL constructs reads on using information about function 
in 1 st language to translate a first program into a second program file - see pg. 1344 Runtime 
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efficiency: mapping, compiler)', hence discloses for each call in the 1 st program file, retrieving an 
item from the file of description items, and using information description in the item to translate 
the first language function into a call corresponding to the 2 nd language ( Note: DDL and call 
declaration to functions by Shannon - refer to claim 1 1 — read on retrieving item from 
description items; and using this information to translate into a corresponding function call in 
another programming language). 

As per claim 20, refer to rationale as set forth in claims 12-13. 

As per claim 29, this is the computer-medium product version of claim 1, hence is 
rejected with the corresponding rejection as set forth therein. 

As per claims 30-35, these are the computer product claims corresponding to claims 12- 
13; hence are rejected with the corresponding rejections as set forth therein respectively. 

As per claim 39, this is the computer-medium product version of claim 1 1, hence is 
rejected with the corresponding rejection as set forth therein. 

As per claims 40-41, these are the computer product claims corresponding to claims 12- 
13; hence are rejected with the corresponding rejections as set forth therein respectively. 

As per claim 45, this is the computer-medium product version of claim 17, hence is 
rejected with the corresponding rejection as set forth therein. 

As per claim 48, refer to rationale as set forth in claims 12-13. 

Claim Rejections - 35 USC §103 
9. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
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having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

10. Claims 8-10, 14-16, 18-19, 36-38, 42-44 and 46-47 are rejected under 35 U.S.C 103(a) 
as being unpatentable over Shannon et al., "Mapping the Interface Description Language Type 
Model in C", November 1989, IEEE Transactions on Software Engineering, Vol. 15, No. 1 1, in 
view of Bjarne Stroustrup, "the C++ Programming Language", 2 nd Edition, copyright 1991 
(hereinafter Stroustrup). 

As per claim 8, Namespace and function scope involving local and global parameters are 
known in 4 th generation like C. Stroustrup discloses C programming language and namespace 
for addressing scope of members of a function dictated within a declaration directives of such 
namespace ( see pg. 634, chp. 3.3. 1). Hence, it would have been obvious for one skill in the art 
at the time the invention was made in light of Shannon type checking and preprocessing for 
runtime efficiency to implement a function scope for analysis in the definition processing of the 
first language in order to derive a correct scope when effecting a C function declaration 
according to Stroustrup; because this would support the scope of definition of parameters by 
Shannon's C directives because this helps support scope of members within a class or function 
definition as endeavored by Shannon's preprocessing macro directives ( see Shannon: pg. 1341- 
1344). 

As per claims 9 and 10, Shannon does not explicitly teach determining of variable 
arguments in a function and a variable return of results. But according to Stroustrup' s teaching of 
C++ providing a variable number of arguments, e.g. input arglist[], or argv[]; or a variable 
output/return in form of an array, or pointer to a struct or linked list (Stroustrup: argv[]- chp. 
3.1.6, pg. 87; pg. 485 chp. 3.4; argument ... list - chp. 8.2.5 - pg, 532), this a known concept C 
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construction at the time the invention was made. Hence, for one skill in the art at the time the 
invention was made, determining whether a function to have a variable input arguments or return 
variables would also have been obvious according the above teaching by Stroustrup to address 
possibility where number of arguments can vary, and analyzing and precisely controlling on such 
extensibility and variability of parameters as endeavored by Shannon' s type and code checking 
for runtime as set forth above would allow the target code to accommodate for such eventuality, 
using the known approach provided by C as mentioned above. 

As per claims 14-16, refer to the rationale of claims 8-10. 

As per claims 18-19, these claims subject matter fall under the ambit of the subject 
matter of claims 15-16; and are rejected using to rationale as set forth in claims 15-16, 
respectively. 

As per claims 36-38, these are the computer product claims corresponding to claims 14- 
16; hence are rejected with the corresponding rejections as set forth therein respectively. 

As per claims 42-44, these are the computer product claims corresponding to claims 14- 
16; hence are rejected with the corresponding rejections as set forth therein respectively. 

As per claims 46-47, these claims correspond to the subject matter of claims 15-16; and 
are rejected using to rationale as set forth in claims 15-16, respectively. 

11. Claims 21-28, and 49-56 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Elmroth et aL, "A Web Computing Environment for the SLICOT Library", December 2000, 
Brite-Euram III, Networks Programme NICONET, in view of Research Systems, "EDL", 
copyright 1994, further in view of Shannon et al., "Mapping the Interface Description Language 
Type Model in C", November 1989, IEEE Transactions on Software Engineering. 
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As per claim 21, Elmroth discloses a method comprising: 

providing a library file including functions defined by a first language (e.g. SLICOT 
Library, BIAS, LAPACK - pg. 1, Introduction; Riccati equations - Fig. 2-3; . ..uploaded . . . 
Matlab files, data files, Latex, Scilab - pg. 2, pg. 6, Fig. 1,4- Note: uploaded matrices in 
Matlab or Latex format , or Riccati equations read on library files - i.e. files served as input to a 
library generating tool - defined in one language, all such file integrated into the SLICOT library 
file framework); 

processing the library file to create a function library (e.g. SLICOT Routines - Fig. 6) and 
a description file (e.g. PHP scripts - pg. 6-7), the function library including one or more 
functions defined by a second language, each function in the function library being translated 
version of a function in the library file (e.g. SLICOT routines - pg. 6; . ..written in C or Fortran 
- pg.8: Conclusions and Future Work), and 

using the description file to translate a program file from the first language into the 
second language (e.g. SLICOT routines, Matlab binaries, PHP scripts - pg. 7-8 - Note: library 
files xxxxMD or xxxOD files in conjunction with PHP scripts and converting math functions 
into m-files read on one or more functions translated from the library file in a second language, 
i.e. Matlab binaries function files) 

But Elmroth does not explicitly disclose the description file including description 
information being sufficient to enable translation of a call to the function into a call to a 
corresponding function in a second language without requiring processing of the definition of the 
function; nor does Elmroth disclose that each call in the program file to a function in the library 
file is translated into a call to a corresponding function in the second language. Converting math 
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functions into another program like high-level programming language like Fortran or C 
(analogous to suggestion by Elmroth - pg. 8: Conclusions and Future Work) was a known 
concept at the time the invention was made. Research_Systems, as set forth in claim 1, discloses 
definition language (IDL) and mapping various application functions to a fourth-generation 
programming language like C, and using such DDL file, i.e. description file similar to PHP scripts 
by Elmroth, to implement applications similar to the Riccati Equations or Matlab files by 
Elmroth, e.g. Math functions, graph plotting, Image Processing (see Research_Sy stems, pg. 1-5). 
The high-level definition description file by Research_Systems was an interactive definition 
language (DDL) well known at the time the invention was made for converting functions in one 
language into a corresponding functions in another language, like from Math functions to C 
program as taught by ResearchjSystems. As set forth in claim 1, Shannon in a similar approach 
as ResearchjSystems, also discloses mapping functions from one language to syntax and 
constructs implemented in C functions ( re claim 1). Hence, it would have been obvious for one 
of ordinary skill in the art at the time the invention was made to provide an EDL as taught by 
Reseach_Systems and Shannon to enhance the scripts by Elmroth so that the IDL description 
information is used instead of the PHP scripts, the IDL providing sufficient description 
information as to enable translation of a call to the function into a call to a corresponding 
function in a second language without requiring processing of the definition of the function; such 
that each call in the first language program file to a function in the library file is translated into a 
call to a corresponding function in the second language ( re claim 1 : Shannon). The benefits of 
using EDL would have been obvious because of the same reasons listed by Shannon: the EDL 
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provides type safe implementation into a high-level programming like C, and further does not 
require processing of the definition of the function ( see Shannon: Introduction, pg. 1333-1334). 

As per claim 22, this claim includes the limitation as to translate a call to the function 
into a call to a corresponding function in a second language as in claim 21 ; hence is rejected as 
set forth therein. Further, Elmroth discloses a translated version of each function in the library 
file (SLICOT Library, BLAS f LAPACK- pg. 1, Introduction; Riccati equations - Fig. 2-3; 
. ..uploaded . . . Matlab files, data files, Latex, Scilab - pg. 2, pg, 6, Fig. 1, 4- Note: uploaded 
matrices in Matlab or Latex format , or Riccati equations read on functions in the library file - 
i.e. files served as input to a library generating tool - defined in one language, all such file 
integrated into the SLICOT library file framework). 

As per claim 23, this claim limitations correspond to those of claim 3; hence are rejected 
as have been addressed in claim 3, using most of Shannon teachings, mapping of function using 
a description file derived from examining a function in the first language library file, in light of 
Research_Systems. 

As per claims 24 and 25, these claims correspond to limitations of claim 3, 4 and 11; 
hence are rejected using the corresponding Shannon's teachings in view of the rationale to 
combine Elmroth, Research_Systems and Shannon as set forth above. 

As per claim 26-28, Elmroth discloses a Web call mapping and converting interface 
(Fig. 6), while Shannon discloses an interface to check call for error and type violation (the User 
Interface - pg. 1344). In light of the rationale as to combine the IDL teachings by Shannon with 
Elmroth 5 s web interface and PHP scripts, the motivation to provide Elmroth' s Web interface a 
function evaluation interface as suggested by Shannon would have been for the same reasons as 
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combining Elmroth with Shannon as in claim 21. Further, Elmroth does not specify variable 
input descriptor, variable output descriptor, descriptor for a known number of input or output 
arguments as recited in claims 18-20. In view of the rationale to combine Elmroth with the IDL 
by Research_Systems and Shannon, these claims will be rejected as in claims 18-20 respectively. 

As per claim 49, this is the computer-medium product version of claim 21, hence is 
rejected with the corresponding rejection as set forth therein. 

As per claims 50-56, these are the computer product claims corresponding to claims 22- 
28; hence are rejected with the corresponding rejections as set forth therein respectively. 

Response to Arguments 
12. Applicant's arguments filed 1 1/22/2005 have been fully considered but they are moot or 
not persuasive. Following are the Examiner's corresponding counterpoints. 

Rejections under 35 USC §103(a): 
(A) As for claims 1 and 29, Applicants have submitted that Shannon uses data structure 
declarations for mapping one language onto another whereas functions unlike data structures, act 
on structures; hence does not teach or suggest functions in one language are mapped to another 
(Appl. Rmrks, pg. 3, middle). This is not persuasive. First, there is no reciting of any specific 
implementation in the claim that enforces that functions must act of structures; or that a function 
call has been actually translated for that matter. Second, as claimed, a description information is 
described as 'being sufficient to enable translation of a call to the function into a corresponding 
function in a second language'; and this leads to a broad range of possibilities, and is subject to a 
deficiency of USC 1 12, 2 nd paragraph. The absence of action taken to enable the yielding of a 
result has been subject to a USC 101 type of rejection. Shannon discloses DDL, and EDL is 
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known to be information of metadata code construct to support translation of code constructs 
from heterogeneous sources into a targeted programming language different from said source 
languages ( see Shannon: introduction pg. 1333). In fact, Shannon's EDL provides such metadata 
(or description file) which implicates a first language constructs from existing programming 
language constructs in a first source and a target language constructs of a language other than the 
first source language because a second or target language by itself would not require a tool to 
provide conversion/interface definition language and mapping as taught by Shannon ( see 
rejection of claim 1). For one skill in the art, IDL is a interfacing form of language being used 
for mapping constructs of a targeted code language; and EDL starts from a base conceptual 
constructs of existing procedural programming language; and this IDL is providing sufficient 
information to enable translation of one code construct into another; and the rejection has pointed 
out parts where Shannon is expressing functions in IDL, and where it is used to implement target 
code in a compilation or runtime. The runtime of code being effectuated or linked via the use of 
IDL constructs during a preprocessing stage is perceived as code translation of functions call, the 
executable substance of which has been founded on the information from said IDL; hence 
Shannon has met £ being sufficient to enable translation of a call to the function into a 
corresponding function in a second language' because there would be no runtime code from a 
compiler if all the declared function constructs being defined in a IDL remain static IDL 
metadata, i.e. not dynamically instantiated into executables or translated into effective binaries in 
order to effect a function call ( see Shannon: pg. 1341 -> 1344). As mentioned above, absent 
any specifics in the claim as to enforce a particular way to translate a call, what is recited is 
subject to broad interpretation; and the EDL by Shannon has met such interpreted aspect of the 
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claim. Applicant's arguments fail to comply with 37 CFR 1 . 1 1 1(b) because they amount to a 
general allegation that the claims define a patentable invention without specifically pointing out 
how the language of the claims patentably distinguishes them from the references. 

Besides, claims 1 and 29 rejection, however, has been redirected to fall under a new 
ground of rejection. 

(B ) Applicants have submitted that the Examiner is incorrectly confusing the translation of a 
a function with translation of a call to a function to a call to a corresponding function( Appl. 
Rmrks, pg. 3, bottom- pg. 6). It is noted that the IDL tool is to provide all the necessary 
description information enabling a target language to be converted therefrom. Because the claim 
does not recite more specifics as to enable one skill in the art to acquire adequate understanding 
behind the concept of translating a call into a call (to a corresponding function), such call 
translation has been interpreted broadly as a translation of a function for a runtime using a IDL 
definition by Shannon, i.e. effect code constructs in a another programming language in Shannon 
runtime. Thus the linking as set forth in the rejection reads on function calls translated from IDL 
definition based on a first language constructs (see Shannon: . . .data structures found in 
procedural programming languages - 2 nd para, right column, pg. 1334; node declaration ... 
function => name; String; parameters: Seq of ...formal parameters, pg. 1334, right column; 
class, function - Fig. 1 pg. 1335 ); hence Shannon has disclosed such translation of a call via 
translation of a function for a runtime using said IDL definition of a function. As set forth 
above, the claim is not providing specifics as to what this translation amounts to; nor does the 
claim clearly provides a executed translation step whereas in fact the claimed description 
information is merely recited as 'sufficient to enable translation of a call. . . a vague limitation 
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that has been object of a USC 101 rejection. Applicant's arguments fail to comply with 37 
CFR 1. 1 1 1(b) because they amount to a general allegation that the claims define a patentable 
invention without specifically pointing out how the language of the claims patentably 
distinguishes them from the references. 

(C ) Applicants submitted that Examiner is mixing Shannon's DDL with Interactive Data 
Language (Appl. Rmrks, pg. 4, middle ). This argument is now moot in view of the new 
grounds of rejection. 

(D) As to arguments on claims 2-10, 30-38, Applicants have submitted that there is no 
teaching or suggestion from the references in view of the patentability of the base claims ( Appl. 
Rmrks, pg. 5, middle). This argument is now moot in view of the new grounds of rejection. 

(E) Applicants have submitted that the subject matter of claims 1 1 and 49 is not disclosed by 
Shannon in view of Research Systems (Appl. Rmrks, pg. 6, middle ). This argument is now moot 
in view of the new grounds of rejection. And concerning the arguments about claims 12-20, 40- 
48 (Appl. Rmrks, pg. 6, bottom), they are moot for the same reason. 

(F) As for claims 21 and 49, Applicants have submitted that Elmroth in view of Research 
Systems and Shannon, alone or in combination, does not teach the claimed subject matter 
thereof (Appl. Rmrks, pg. 7-8). As set forth in the previous Office Action's Response to 
Arguments, there is no reciting of 'source language' in any of these claims; and besides, alleging 
that the references do not have what is claimed is not necessarily convincing and specifically 
pointing out what distinguishes the claim from the prior art. The referred to parts of Elmroth, 
Research Systems, or Shannon will stand as fulfilling the limitations in view of the lack of 
specifics in the claim and the broad reasonable interpretation that have been applied when 
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construing the limitations as superficially recited, and in view of the teachings suggesting a 
possibility for a useful combination. Applicants contend with repeating that neither one of 
references suggests or teaches the elements of the claim, without showing where in the 
references as set forth by the rejection such non-teaching exists. The sections as set forth above 
have addressed on the arguments revolving around the 'description information being sufficient 
to enable translation . . . second language'. Applicant's arguments fail to comply with 37 
CFR 1.111 (b) because they amount to a general allegation that the claims define a patentable 
invention without specifically pointing out how the language of the claims patentably 
distinguishes them from the references. 

For the above observations, the rejection will stand as set forth above. 

Conclusion 

13. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Tuan A Vu whose telephone number is (272) 272-3735. The 
examiner can normally be reached on 8AM-4:30PM/Mon-Fri. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Kakali Chaki can be reached on (571)272-3719. 

The fax phone number for the organization where this application or proceeding is 
assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before 
using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571- 
272-3609. 

Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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